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REMARKS/ARGUMENTS 
These nraarks are made in response to the Office Action of July 2, 2004 (Office Action). 

As this response is timely filed within the 3-raonth shortened statutory period, no fee is beUeved 
due. 

In parajiraphs 2 and 3 of the Office Action, claims 1-2, 10, 16-17. 24-25, 33. and 39-40 
and 47 have buen rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent 
Number 6.36- .421 to Baiker et al (Barker) in view of U.S. Patent PubUcation No. 
2002/0169878 i;o Orenshteyn (Qrenshteyn). In paragraph 4 of the Office Action, claims 5-9, U, 
13-15, 20-22, :'.8-32, 34, 36-38, and 43-45 have been rejected under 35 U.S.C. § 103(a) as being 
unpatentable ever Barker in view of Orenshteyn and in fUrther view of Sun Microsystems: 
JAVA2 Mauajjement Extensions White Paper, Dynamic Managcancnt for the Service Age ^ 
(JAVA2). In X aragraph 5, claims 12. 23, 35, and 46 have been rejected under 35 U.S.C. § 103(a) g 
as being unpatentable over under Barker in view of Orenshtej-n in fUrther view of JAVA2, in yj 
further view ol* U.S. Patent Number 6,633,923 to Kukura et al. (Kukura). ^ 

Prior tc. addressing the rejections on the art. a brief review of the Applicants' invention is — 
in order. Applicants disclose a system, method, and apparatus for managing resources of an < 
application, where the application runs within a distributed environment havmg appUcation jO 
components rssiding within different software machines, each of which can reside upon a 
different host ..'omputer. Each software machine can be a virtual machine, such as a Java Virtual 
Machine. Dintributed application components can utilize remotely located resources residing 
within one or more software machines. Communications between the application components 
and the software machines can be utilize a centralized communication mtermediary. 
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More s;)ecifically. the ^sclosed system includes a master agent that can receive 
management ctimmands from several different application components. The master agent can 
direct received commands to mini-agents that are each coupled to one or more application 
resources. Each mim-agcnt can handle local overhead for the application resources, triggering 
the utilization of these localized resources responsive to the management commands received 
from the master agent. Moreover, each mini-agent can be communicatively linked to and 
registered with the master agent. The master agent can communicate with each mini-agent using 
standardized commands, which are translated by the mini-agents into local commands specific to 
the local applic ation resources managed by each mini-agent. 

By decoupling application components (software routines that consume resources) from 
application renources consumed during program execution (manageable resources locally 
managed by the mini-agents), apphcations can be easily be deployed in a distributed computing 
space. Accorc lngly. the master agent can function as a layer of abstraction between application 
components consuming resources and the resources consumed. Each mini-agent can translate 
standard commands issued by the master agent to a local environment. 

Turning specifically to the rejections on the ait, in paragraphs 2 and 3 of the Office 
Action, claims 1-2, 10, 16-17, 24-25. 33. and 39-40 and 47 have been rejected under 35 U.S.C. 
§ 103(a) as being unpatentable over Barker in view of Orenshteyn. 

Barker is not directed towards the problems with deploying app^cattons within a 
distributed ccmputing space. Instead, Barker teaches a Web-based administrative tool for 
remotely mamiging network hardware associated with a network server. In Barker, the network 
hardware is « ferred to as a network element 14 defined as "(a device) responsible for processing 

12 

PAGE 14126 ' RCVD AT 919120043:47:47 PM [Eastern Daylight Time] * SVR:USPT0-EF)(RF-1/l * DNIS:8729308 * CSID:S616S96313 ' DURATION (niin-ss);07-54 



SEP-09-04 15:55 Fron:AKERUAN,SENTERFITT (i EIDSON 

A{>p]o. No. 09/649 12) 
Amendment dated Sep. 9, 2004 
Reply to Office Action of July 2, 2004 
Docket No. 6169-170 



5616596313 T-410 P. 15/26 Job-643 

reM Docket No, 0009-2000^37 



event and alana notifications to. the element management system via SNMP ..." as stated at 
column 4. Un«! 56-59. Barker teaches that an Web browser can be used as the remote Web- 
based admioistrative tool in lieu of an administrative interface local to the network server. 
Contemplated interfaces for the Web browser are shown in FIGS. 10-13. 

One skilled in the art recognizes that SNMP refers to the Simple Network Management 
Protocol (SNMP) that is a network management protocol used in TCP/IP networks. SNMP is 
used to manag.) network device^, such as hubs, routers, bridges, etc. In SNMP. data is passed 
from SNMP anents that report activity of associated network devices to a workstation console 
that oversees tlie network. The workstation console relies upon a Management Information Base 
(MIB), which is a data structure that defines what is obtainable from the network device and 
what device operations can be cqntrolled (turned off, on, etc.). 

It shou d be appreciated by one of ordinary skill in the art that SNMP is not a protocol 
conventionally uaed to facilitate the distribution of applicatioas across a distributed computing 
space. Instead, SNMP is weU tailored for low-level (hardware) communicationa between 
network elem<.'nts, which is hqw it is utilized in Barker's teachings. The low-level SNMP 
communicatiojis are conveyed directly from network elements to server, network elements 
(hubs, bridges etc.) communicating via SNMP are not disposed within software machines (like 
JAVA VIRTUAL MACHINES), but instead directly attached at a low level. 

In contrast, application management is a higher-level (appUcation level) communication 
that occurs b«!tween appUcation components. This higher level communication can involve 
significant overhead (handled by the master agent and the mini-agent) necessary for an 
application component to utilize application resources. No equivalent structures, architectures. 
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or concepts ar. taught or contemplated by Barker That is, Barker solves a different and 
unrelated problem (remotely managing network elements) than that solved by the Applicants. 
Barker is in a non-analogous field of endeavor from the Applicants claimed and disclosed 
invention. 

Refemi.g to independent claims 1, 10. 16, 24. 33, and 39, the Applicants explicitly claim 
the following: 

(1) -in applicant manager in a first application host that is a software 
macbin e configured to interpret compiled machine-independent code 

(2) J master agent in a second application host that is a software macblae 

(3) ii plurality of mini-agents, each in an application host (different from the 
first an< I second hosts) thjit is a software machine 

(4) ihe application manager conveying commands to the master agent (that 
require)! at least one resource), the master agent conveying a corresponding 
command to the mini-agent, the mini agent performing an operation responsive to 
the received command, the operation (utilizing the resouj-ce). 

Barker is cited as teaching an application manager in ft first application host, a master 
agent in a seccnd application host, and a mini-agent in a third application host. Barker provides 
no such teachings. Instead, Barker teaches a network manager, a Sl iMP ^ge"t and a SNM£ 
agent, as shown by FIGS 3 and 4. Barker fails to teach or suggest an applicatioii host. Barker 
also faUs to tesich or suggest a master agent or a mini-agent as claimed by the Applicants. 

Applicants are confused as to the exact elements that the Examiner believes to be 

equivalent to Ihe elements of *e disclosed invention. Specifically, the Examiner recurrenUy 

cites lines 24-:i4 of column 1 attd FIG. 3 for teaching: the application hosts, application manager, 

the master agent, and the mini-agents. This passage indicates that a network element linked to a 

server can be managed from a client. This passage fails to mention master agents, mini-agents, 

or any system capable of managing distributed applications. 
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PresuniJibly, the Exammer is stating the element management system client 28 is 
equivalent to the first appUcation host, the element management system server 32 is equivalent 
to the second application host, and the application processor 80 (within the networic element) or 
perhaps the network clement itself? is equivalent to the remote application hosts. 

Applicants teach that thp first application host includes an application manager that 
initiates manai cment commands to perform at least one management operation directed to at 
least one management resource. Presumably, the application manager is the represented by 
FIGS. lO-U. 

AppHcj-nis also teach that the second application host includes a master agent. 
Applicants ass';tfne that the Examiner intends the object server 66 to be equivalent to the master 
agent. The object server 66 is generically defined at colunm 5, lines 35-40 as being a "single 
Unix process that provides most of the element management s>'stem server functionality." This 
assumption is made since this is the only illustrated component of the element management 
server 32 linJc?d to the HTTP Web server component 58 and the HPOV procesaea 70» which 
provide a conununication link to the element management system client and the application 

processor resp actively. 

AppUcwts further teach that the remote application hosts, each include a mini-agent. 
Applicants assume that the SNMP agent 81 is supposed to be equivalent to the mini agent. 

Based upon these assumptions, Applicants conclude that Barker fails to contemplate an 
application be st. As noted on page 12, lines 23-27. an application host can be an operating 
system session, a virtual machine or any other suitable process address space in which programs 
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can execute. P;irther, the claims define an appUcation host to be a software machine configured 
to interpret conr piled machine independent code. 

The Ex{.roiner references column I. lines 24-35 and FIG. 3 as teaching applications hosts. 
Presumably, tho Examiner is claiming that items 32, 28. and 80 are "application hosts". Instead, 
each of the items 32, 28, and 80 are different types of hardware (namely a server, client, and a 
network element), none of which are defined as (or defined as including) software machines for 
interpreting code. Definitions in the specification (and in FIG. 2) detail the stnichire intended for 
items 32, 28, aiid 80, none of which include, imply, or infer a software machine. 

The ele nent management system server 32 is defined in FIG. 2 as including items 46. 48. 
52. 55, 47. 54. 56, and 49, each typical of a robust hardware server hosting many Web 
applications. The components of the element management system server 32 is exhaustively 
detailed starting at column 8, line 1 ending at column 26 line 45. The detaUed components are 
not onea conventionally present in a software machine. One of ordinary skill would not equate 
the elemwt mwagement system server 32 with a software machine or with an application host 
as defined and claimed by the Applicants. 

The el ement management system client 28 is defined in FIG. 2 as including a Web 
browser 45 w th many included JAVA applications 44. While these JAVA applications may 
very well utilise a software machine (like a JVM) to execute, the Web browser 45 as iUustrated 
would not Fi rther, the element management system client 28 is listed in FIG. lA as including a 
management computer 26. T^ie client interface of the management compute 26 supports " 
Microsoft Internet Explorer and Netscape browsers as well as Web-enabled devices for PCs and 
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X-Tenninals (as noted at column 4, lines 18-26). It is evident that the element management 
system client 211 is different from the application host defined and claimed by the Applicants. 

The netvork element 14 is a hardware device (like a hub) for processing event and alarm 
notificarions to the clement management system via SNMP (as noted at column 4. lines 56-59). 
Such devices Jire not software machines or application hosts as defined and claimed by the 
Applicants. 

Barker Fails to contemplate a master agent, A master agent, as noted at page 13 lines 9- 
17, can respond to application manager commands without requiring the application managers to 
have specific Knowledge of the particular application hosts in which the manageable resources 
reside. 

In conti ast, the object server 66 includes elements shown in FIG. 4, that permit the object 
server 66 to hjindle predetermined events, such as handling alarms via the alarm manager 120. 
The object seiver 66 is designisd to accept specific client requests directed towards network 
elements at KITOWN network locations. Otherwise system administrators using the client 28 to 
manage netwo rk elements, cannot troubleshoot/ properly maintain the network elements when an 
alarai sounds. The object server 66 does not perform the same function (or any remotely similar 
function to) tb a master agent as claimed by the Applicants. 

Barker fails to contemplate a mini-agent. A mini-agent 24 includes a registry of 
manageable resources 26 that are exposed to the master agent 22. The mini-agent 24 is a local 
bifurcation of an agent layer as noted at page 1 3, lines 9-17, which is responsible for handling all 
activities pertiiining to managed resources. As such, the mini-agent can register capabUities of 
managed resources that can be remotely accessed by the master agent 22. 
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In contrast, an SNMP agent is a management entity consisting of hardware and embedded 
software whicl responds to SNMP requests over Ethernet from an SNMP manager. SNMP 
agents and SNJ-IP managers share a database of information, called the Management Information 
Based (MOB). Capabilities of the SNMP agent and MIB are defined by the Request for 
Comments (RI'C) 1157. RFC 1157 is a standard that gathers statistical data about network 
traffic and the aehavior of network components. RFC 1 157 does not specify that SNMP agents 
are to register <=xposed capabilities. Further RFC 1 157 defines SNMP as a protocol for managing 
networked devices designed as a standardized message conveyance, device querying protocol. 
RFC 1157 has nothing to do with managing applications d^Ioyed within a distributed 
computing spa^e or with linking resources to these distributed applications. Further, one skilled 
in the art would not turn to RFC 1157 or its enhancements for teachings pertaining to deploying 
applications w thin a distributed computing space. 

The Etaminer cites column 4, lines 56-59 as teaching a registry and a command 
execution scheme. The cited lines merely reference the MIB of the SNMP protocol (defined by 
RFC 1157), which the Examiner has misinterpreted as being equivalent to a registry (exposing 
executable methods) of the mini-agent. By definition (RFC 1157) the SNMP agent 81 
CANNOT be ::anctional equivalent to the mini-agent 24. 

Insteac, the MID is a database of network management information that is used and 
maintained b> a network management protocol such as SNMP or CMIP. The value of a MIB 
object can be changed or retrieved using SNMP or CMIP commands, usually through a GUI 
network raan?gement system. MIB objects are organized in a tree structure that includes public 
(standard) an.! private (proprietary) branches. Again, the MJB does not expose executable 
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methods to a tiiaster agent, as does the registry associated with a nuni-agent as defined in the 

Applicants' spejification. 

Orenshleyn fails to cure the deficiencies of Barker. Qrenshteyn fails to teach or suggest a 
master agent ai.d/or a mini-agent Instead, Orenshteyn teaches a means to rettieve an application 
ftom a remote location (securely) and to execute the retried application. That is, Orenshteyn 
teaches a rem:)te server authentication methodology. Orenshteyn has nothing to do with 
remotely distrilmting applications or with remotely managing a network. 

Not on y does Orenshteyn fail to cure the deficiencies of Barker, but it is improper to 
combine teachings of Orenshteyn with teachings of Barker in the manner suggested by the 
Examiner. Or.;nshteyn is cited (page 2, paragraph 17) for teaclaing that an application host can 
be a software machine. The cited paragraph details that progratns can be executed upon a client 
machine by first downloading an executable file, then executing the download file upon a client 
machine. The downloaded file can be a JAVA file interpretfsd by a JAVA interpreter. This 
teaching has nothing to do with network traffic, network elements, or SNMP. 

The network element 14 of Barker is generally a fixed hardware device, like a hub. 
Barker never suggests that the network element 14 is to remotely execute remote programs, 
which seems .i bizarre thing for a network element to do. To add this capability, a network 
element woul<i have to be extended to include a updatable memory (most likely a persistent 
memory like ii hard drive) upon which programs can be downloaded/executed and a software 
interpreter. Tliis update would be costly and result in a potentially large exploitable security 
flaw. Neither Barker, Orenshteyn, or combinations thereof teach or suggest such a modification. 
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Moreover, Oreiifihteyn actually provides no teachings relevant to SNMP or to managing network 
devices, in gen«iral. 

In paraiyaph 4 of the Office Action, claims 5-9, 11, 13-15. 20-22. 28-32, 34, 36-38. and 
43-45 have been rejected under 35 U.S.C. § 103(a) as being unpatentable over Barker in view of 
Orenshteyn aiwl in turther view of JAVA2. JAVA2 fails to cure the deficiencies of Barker and 
Orenshteyn. That is, JAVA2 fails to teach or suggest a application host, a master agent and/or a 
mini-agent, as claimed by the Applicants. Instead. JAVA2 is a generic White paper concerning 
JMX, which ths Applicants do not claim to have invented. 

It is not proper to combine the JAVA2 reference and the Barker reference for purposes of 
rejecting the >^.pplicants claims, as neither reference teach or suggest the combinations asserted 
by the Examiner as obvious. Further, the suggested combination would fail to further the 
purpose of the Barker reference, which is to remotely administrate network elements. 

The E> arainer cites page 6 of JAVA2 as the motivation to combine references. The a 
paragraph does mentton that protocol adaptors can be used to let external applications access a 
JMX agent ar.d the MBeans cantained within the agent. Barker, however. faUs to teach or 
suggest using nviX agents or MBeans. There is no reason that MBeans would be located within 
the network eliiments used within Barker. 

Applicants believe the Bxaminer is confused by the term agent and has inadvertently 
assumed an SNMP agent (defined by RFC 1157) is the same as a JMX agent (defined by the 
JMX architeciure). Combining the references as suggested would require the use of BOTH an 
SNMP agent AND a JMX agent, as the two are fundamentally dissimilar and server different 
purposes. 
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Consequently, one of ordinary skill in the art femiliar with JXM (and the material within 
the White Paper) would not contemplate using MBeans within a network element 14 described m 
Barker. Barkei" is not attempting to redefine network elements, which do not generally include 
MBcans. Instep Barker teach^a using a client interface to remotely manage network devices. 
Unless MBeans were commonly contained within hubs, bridges, and other network elements 
(which they w ere and are still, not) one would never contemplate adding a JMX agent to 
reference these beans (that would not exist). Certainly, Barker offers no teachings in this regard. 

Referring to claim 5. Applicants claim that a master agent includes a JMX 
communication connector for communicating with the application manager and the mini-agents. 
Barker teaches that the object server (held to be equivalent to the master agent) is to 
communicate to the element management system client (held to be equivalent to the application 
manner) usins: a HTTP Web server. Barker ftirther teaches that the object server is to 
communicate io the network element (held to be equivalent to the mini-agent) through HPOV 
processes 70). Applicants do not know where in the object server the Examiner proposea to add 
a JMX comm\mication connector or how such a connector would affect the HTTP Web Server 
58 and the HPOV processes 70. Regardless, Barker foils to teach or suggest such an 

arrangement- 
Referring to claim 6. Applicants claim adding a JMX communication protocol adaptor to 
the master ag<^m to provide a protocol adapted view to the application manager. This makes no 
sense in terms of the Barker disclosure. Why would it be desirable to add a JMX protocol 
adaptor to the Object Server 6^ to provide a protocol adapted view to the network interface of 
FIGS. 10-13? Barker suggests ^lo such arrangement, nor does Orenshteyn, nor does JAVA2. 
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Refertirg to claim 7, Barker does not teach or suggest that the Object Server is to 
remotely invoke any method. Such attempts would interfere with the SNMP mediator's 160 
attempts to configure and poll requests/responses. It would not be advantageous for the element 
management s<.rver 32 to use RMI to invoke methods within network devices that it controls. 
The network nanagement server 32 is instead directly linked to managed network elements 
using a low-level protocol, hke SNMP. Accordingly. Barker fails to teach or suggest the use of 
RMI between the server and the network element. 

Referring to claim 8, Barker fails to teach or contemplate network elements that include 
MBeans. Evc;i if network elements internally included MBeans (for some unknown reason - 
MBeans result in substantial overhead not advantageous to netv/ork elements like hubs, bridges, 
routers) Applisants do not believe that it would be a good idea (nor obvious to a software 
developer) to provide an interface that would allow the MBejins to be manipulated. Such an 
interface woul i permit people having access to the network element to meddle with the MBeans. 
which would 1 ©present a signifKant network weakness or exploitable flaw, without resulting in 
any discemable benefit. Barker fails to teach or suggest network elements including MBeans, 
nor does Oren ihteyn. nor does JAVA2. Neither to these references teach that an interface should 
be provided tc- manipulate MBeans within a network element (which does not typically include 
any MBeans). 

Further, claims 12, 23, 35, and 46 have been rejected under 35 U.S.C. § 103(a) as being 
unpatentable ever under Barker in view of Orenshteyn in further view of JAVA2. in fiulher view 
ofKukura. Biukura fails to cure the deficiencies of Barker. Orenshteyn, and JAVA2. That is, 
Kukura fails to teach or suggest a application host, a master agent and/or a mini-agent, as 
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claimed by the Applicants. Inst^, Kukura is referenced because it uses RMI. Kukuraisnot 
felated to Barksr in any fashion, and there is no motivation within the references to form the 

combination sujjgested by the Examiner. 

Instead. M mentioned above in reference to claim 7. Applicants know of no reason to use 
RMI to conununicate between the network server of Barker and the network elements of Barker. 
Such a use seems to be counterintuitive to the purposes served by Barker. Regardless, neither 
Barker, Orenst teyn, JAVA2. nor Kukura provide any rational as to why a RMI should be used 
between a network server and network elements. Hence, no proper motivation exists to combine 
the references. 

As not.5d above, neither Barker, Orenshteyn, JAVA2, Kukura, nor any combinations 
therein teach cr suggest an application host, an application maj^ager, a master agent, or a mini- 
agent. Further, neither Barker, Orenshteyn, JAVA2, Kukura, nor any combinations therein teach 
or suggest an architecmre that facUitates the use of remotely located resources by distributed 
applications, u taught and claimed by the inventors. Additionally, no motivation exists to 
combine the rsferenoes Barker, Orenshteyn, JAVA2, and Kukura for purposes of 35 U.S.C, § 
103(a). Cons,5quently. the 35 U.S.C. § 103(a) rejections to claims 1-47 should be withdrawn, 
which action i i respectfully requested, 

Appliciints believe that this application is now in full condition for allowance, which 
action is resp.:ctfully requested- Applicants request tftat the Examiner call the undersigned if 
clarification u needed on any matter within this Amendment, or if the Examiner believes a 
telephone inteiview would expedite the prosecution of the subject application to completion. 
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